declarative policies（宣言型ポリシー）のベストプラクティスをまとめてみた #AWSreInvent
2024.12.03re:Invet2024に参加している。たかやまです。
先日、AWSが提供するポリシーとして新たにdeclarative policies（宣言型ポリシー）が発表されました。
社内でもdeclarative policiesについて続々とブログが投稿されています。
今回はdeclarative policiesを適用するうえでのベストプラクティスが公開されていたのでをまとめてました。
まとめてみた
Leverage readiness assessments(準備状況評価を活用する)
準備状況評価では、アカウントステータスレポートを使用して 、現在のアカウントのステータス状況の評価を推奨されています。
宣言的ポリシーのアカウントステータスレポートを使用して、スコープ内のアカウントの宣言的ポリシーでサポートされているすべての属性の現在のステータスを評価します。 レポートのスコープに含めるアカウントと組織単位（OU）を選択するか、ルートを選択して組織全体を選択することができます。
このレポートは、地域の内訳を提供し、属性の現在の状態がアカウント間で均一であるか（numberOfMatchedAccountsを通して）、一貫性がないか（numberOfUnmatchedAccountsを通して）、準備状況を評価するのに役立ちます。 また、その属性で最も頻繁に観測される構成値である最頻値も見ることができます。
ベースライン構成を強制するために宣言的なポリシーを添付するかどうかは、特定のユースケースに依存します。
アカウントステータスレポート実施方法はこちらのブログで試しています。
ためしに1つアカウントの東京リージョンでSerial Console Accessを有効にした状態でレポートを作成してみました。
以下のような形で、各属性のリージョンごとに最頻値（ここではSerial Console Accessが無効化）の設定から逸脱している設定が行われているリージョンが検出されるかたちになります。
このレポートの内容から最頻値の状態に寄せるのか、それともそのままの状態にするのかを検討することができます。
アカウント名などの詳細な情報を知りたい場合には、出力先のS3バケットにCSV形式で格納されているのでそちらを確認するかたちとなります。
Start small and then scale(小さく始めて、大きくする)
こちらでは、宣言型ポリシーを適用する場合には影響範囲が小さい単一のテストアカウントの適用から始めることを推奨しています。
デバッグを簡素化するには、テスト ポリシーから始めます。次の変更を行う前に、各変更の動作と影響を検証します。このアプローチにより、エラーや予期しない結果が発生したときに考慮する必要がある変数の数が減ります。
たとえば、重要でないテスト環境で、単一のアカウントにテスト ポリシーを添付することから始めることができます。仕様どおりに動作することを確認した後、ポリシーを組織構造の上位のアカウントや組織単位 (OU) に段階的に移動できます。
以下ではまずはテストアカウントなるSandboxで検証を行い、徐々にDev -> Workloads -> Rootと適用範囲を広げていくことをイメージしています。
例外設定など複数の宣言型ポリシーを適用した場合の挙動についてはこちらのブログを参考にしてください。
Establish review processes(審査プロセスの確立)
こちらでは、宣言型ポリシーの設定内容と組織としてのセキュリティと運用の要件でズレが起きていないか確認することを推奨しています。
宣言型ポリシーで制御されているアカウントに対して、アカウント側から禁止行為の設定を行おうとした場合にはClient.DeclarativePolicyViolationが記録されます。
こちらのログを監視することで、組織全体のセキュリティと実際の運用で乖離が起きてないか判断することができます。
新しい宣言属性を監視し、ポリシー例外を評価し、組織のセキュリティと運用の要件との整合性を維持するための調整を行うプロセスを実装します。
AWS CloudTrail を使用して、宣言型ポリシーの作成、宣言型ポリシーの更新、宣言型ポリシーの削除のプロセスを監査することもできます。CloudTrail は、宣言型ポリシーによる API 操作の失敗にフラグを設定できます。詳細については、「ログ記録とモニタリング」を参照してください。
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html
Validate changes using DescribeEffectivePolicy(DescribeEffectivePolicy を使用した変更の検証)
こちらはDescribeEffectivePolicyを利用して、対象アカウントが意図したポリシーが適用されているか確認することを推奨しています。
宣言型ポリシーに変更を加えた後、変更を加えたレベルより下の代表アカウントの有効なポリシーを確認します。有効なポリシーは、AWS マネジメントコンソール を使用するか、 DescribeEffectivePolicy API オペレーションまたはその AWS CLI または AWS SDK バリアントのいずれかを使用して表示できます。行った変更が有効なポリシーに意図した影響を与えたことを確認します。
ルートOUにSerial Console Accessを無効化する宣言型ポリシーを適用した場合の管理アカウントとSandboxアカウントの状態を確認してみます。
aws organizations describe-effective-policy --policy-type DECLARATIVE_POLICY_EC2
{
"EffectivePolicy": {
"PolicyContent": "{\"ec2_attributes\":{\"serial_console_access\":{\"status\":\"disabled\"}}}",
"LastUpdatedTimestamp": "2024-12-02T18:57:54.020000+00:00",
"TargetId": "<管理アカウントID>",
"PolicyType": "DECLARATIVE_POLICY_EC2"
}
}
aws organizations describe-effective-policy --policy-type DECLARATIVE_POLICY_EC2 --target-id <SandboxアカウントID>
{
"EffectivePolicy": {
"PolicyContent": "{\"ec2_attributes\":{\"serial_console_access\":{\"status\":\"disabled\"}}}",
"LastUpdatedTimestamp": "2024-12-02T22:37:28.372000+00:00",
"TargetId": "<SandboxアカウントID>",
"PolicyType": "DECLARATIVE_POLICY_EC2"
}
}
ここから、Sandboxアカウントに対しては追加のスナップショットブロックパブリックアクセスの宣言的ポリシーを適用してみたいと思います。
aws organizations describe-effective-policy --policy-type DECLARATIVE_POLICY_EC2
{
"EffectivePolicy": {
"PolicyContent": "{\"ec2_attributes\":{\"serial_console_access\":{\"status\":\"disabled\"}}}",
"LastUpdatedTimestamp": "2024-12-02T22:37:28.786000+00:00",
"TargetId": "<管理アカウントID>",
"PolicyType": "DECLARATIVE_POLICY_EC2"
}
}
aws organizations describe-effective-policy --policy-type DECLARATIVE_POLICY_EC2 --target-id <SandboxアカウントID>
{
"EffectivePolicy": {
"PolicyContent": "{\"ec2_attributes\":{\"serial_console_access\":{\"status\":\"disabled\"},\"snapshot_block_public_access\":{\"state\":\"block_all_sharing\"}}}",
"LastUpdatedTimestamp": "2024-12-02T22:45:01.434000+00:00",
"TargetId": "<SandboxアカウントID>",
"PolicyType": "DECLARATIVE_POLICY_EC2"
}
}
Sandboxアカウントについては追加で \"snapshot_block_public_access\":{\"state\":\"block_all_sharing\"}が適用されていることが確認できます。
これにより対象のアカウントに対して意図した宣言的ポリシーが付与されているかを確認することができます。
最後に
宣言的ポリシーは組織でガバナンスを効かせるのに非常に有用な機能です。
一方で、意図しない設定をした場合の最悪組織全体に影響が波及するため、慎重に検討する必要があります。
今回のベストプラクティスが、宣言的ポリシーを適用する際の一助になれば幸いです。
以上、たかやま(@nyan_kotaroo)でした。
![[レポート]Lightning talk「コンプライアンスとコスト管理による可視性と最適化の実現」に参加してきました。#SMB203](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[新サービス] Aurora がマルチリージョンに対応！リージョンを超えて強い一貫性を持つ Amazon Aurora DSQL が発表されました！](https://devio2024-media.developers.io/image/upload/v1733249237/user-gen-eyecatch/kfsc0wisop9s7mb5i0zt.png)
